前言

九、十月是各種雲端與圓體工具研討會、峰會的旺季，也是每年跟一些同業、老同事交流的好機會。前幾天正好與一些數位團隊的Team Lead在研（吃）討（宵）會（夜）上討（抱）論（怨）到應用故事點（Story Points)的經驗和痛點。由於比較少看到有關【敏捷式開發】+【數據團隊】的中文內容，趁這個機會分享一下！

故事點（Story Points)理解與估算辦法

簡單來說，在敏捷開發中，故事點（Story Point）是一種工作量的單位，類似工時（Man Hour)的估計量。但比較有趣的是它是一種基於團隊主觀共識的相對單位，應該是要團隊成員對一個故事的複雜度和不確定性的評估，並給出一個相對的估算值。

故事點的定義與估算有各種技巧與竅門，對敏捷開發有興趣的朋友可以看一下Atlassian這篇文章，我這裡就不細談了。重點是，故事點的估算與理解上需要注意以下幾點：

• 故事點是相對的，而不是絕對的:"1 故事點" 不能用制式工具轉換成 "X 工時"，但2 故事點的一個物件(Item/Task)的工作量應該是大致相等2 x 1 故事點的物件
• 故事點的估算需要經過討論和協商，而不是單靠個人經驗
• 團隊成員需要對故事的複雜度和不確定性有共同的理解

數據團隊上的應用與痛點

雖然說Agile在團體開發已經算是行之有年，但大幅崛起而成為管理上的熱門話題，感覺也是最近5～10年的事。由於很多公司數據團隊通常都是產品或軟體開發團隊衍生出的，所以也經常自然而然的被捲入敏捷式開發的這一套管理觀念。

拜飛機式的敏捷開發暫時不談，其實數據團隊經常有一些特點，在實踐敏捷上容易造成摩擦，而特別多問題會反應在【故事點】這個概念上。

服務性數據團隊（Service Oriented Data Teams):

敏捷式開發的初衷是軟體開發，而目標是針對一個的項目以最快的速度完成定量的工作內容（e.g. 產品backlog）。相對的，很多數據團隊的工作是直接對接一些公司內部的其他團隊，工作性質比較服務性，類似內部的數據產品的客服💁。相對產品開發，團隊的工作項目和內容是不定量的，而各個物件基本上也都是獨立的。

在這種情況下，故事點經常沒有什麼意義。管理者的目標不是了解一個大項目的總體複雜性，而是達到某種程度的服務SLA，而團隊管理方式應該是注重工作的優先性。管道進來的任務逐一完成就行。

團隊專長的不可替代性：

在小公司裡，數據團隊經常是各種數據專長打包在一起的。譬如專長偏後端開發的Data Engineer和前端的Data Analyst會因為都是"Data"被湊在一起。就算是性質相同的數據團隊，譬如純粹的Data Analytics，也會因為對接的內部團隊或者數據組（Dataset)不同而發展出相當程度的特化。

在這種情況下，達成故事點定義中的【故事的複雜度和不確定性有共同的理解】會比較困難，而所需要的討論時間也可能長到不可行。而就算達到了這個共識，也不代表團隊成員可以代替同事完成同樣的物件。在這個狀況下，進行故事點估算其實沒什麼意義，而團隊成員可以直接對各個物件進行時間上的預估來報告項目完成時間。

人為主、法為輔

敏捷式開發是道家，人為主，法為輔，主張「道法自然」
為了寫這篇文查各種敏捷開發中文詞彙時，看到了這個比喻，感覺非常貼切。敏捷式開發的初衷是為了配合軟體開發者工作的性質與節奏，而強調的是按照你的團隊成員與性質改變你的工作方式。如果硬是套用故事點到不適合的數據團隊，那也是可想而知的造成磨合上的問題。